The present invention generally relates to a publish/subscribe network. More particularly, the present invention relates to controlling throughputs of clients connected to a broker device in the publish/subscribe network.
A publish/subscribe is an asynchronous messaging mechanism where message senders (i.e., publisher or publishing client) do not send messages to specific receivers (i.e., subscriber or subscribing client). In a publish/subscribe network, any number of consumers (i.e., subscribers) of information can receive messages that are provided by one or more producers (i.e., publishers) of that information. In this case, a producer of information is called a publisher and a consumer of that information is called a subscriber.
Publish/subscribe messaging provides the concept of a topic on which any number of interested consumers of information can subscribe in order to register their interest. This is similar to the way that a person might subscribe only to magazines about topics in which they are interested. Each topic provides particular event or state information.
A publisher can send messages containing information about a particular topic to all subscribers to that topic, without any knowledge of how many subscribers there are, or the details of the nodes that host those subscribers. Because of this, publish/subscribe messaging completely decouples the provider of the information from the consumer of that information.
In order to facilitate this publish/subscribe capability, a broker device is required to hold information about which subscribers have subscribed to which topics and how to deliver messages to them. A publisher can then publish messages using the broker device to all subscribers on that topic without knowing the details of those subscribers. There can be multiple publishers for a particular topic, and a subscriber to information about one topic can also be a publisher of information about other topics.
The broker device is a component to which clients (i.e., applications or systems) connect to perform publish and subscribe messages. The broker device handles a matching of publications with subscriptions, a distribution of publications to subscribing clients, and a persistence (i.e., storing messages in a non-volatile storage) of messages to ensure message delivery at a quality of service required. The broker device acts as a hub for routing messages between clients, and with the aid of a bridge, other messaging servers. The broker device can store messages on behalf of a client that is not connected and make them available to the client when it reconnects. In addition, the broker device can store messages on behalf of the bridge and make them available when the messaging servers that the bridge connects to are available.
The bridge is an extension of the broker device that routes messages between the broker device and other messaging servers to form sophisticated messaging topologies. The bridge allows messages to be routed between the broker device and, for example, the following messaging servers:                Other broker devices        WebSphere® MQ™        WebSphere® Message Broker device        WebSphere® Application Server        Any JMS (Java® Message Service) provider        
The bridge can route messages between one or more messaging servers. If the bridge cannot connect to a messaging server, messages destined for the messaging server can be stored by the broker device. When the messaging server becomes available, the bridge will connect to it and transfer the stored messages. In addition, the bridge can transfer pending messages from the messaging server to the broker device.
Typically, each type of messaging server supports its own messaging protocol and its own message formats. The bridge plays the role of routing messages across different protocols and transforming messages to a format acceptable by each messaging server.
Message throughput is a rate at which a system can transfer (or submit or deliver) messages. Message throughput is measured in “the number of messages per second”.
In a publish/subscribe network, the publish/subscribe mechanism means that producing clients (i.e., publishers or publishing clients) are decoupled from consuming clients (i.e., subscribers or subscribing clients), which facilitates loosely coupled and flexible messaging environment. However, this decoupling can come at a price since it is perfectly possible for a publisher to publish at a higher rate than a consumer is able to consume, ultimately leading to saturation of a broker device. For example, a local client has a very short path length (e.g., an end-to-end hop counts) into a broker device and is capable of publishing at rates far higher than a bridge in the broker device can move messages from a broker device to a messaging server (e.g., a Websphere® MQ™). A saturation point of the bridge in the broker device is reached when an internal outbound queue for the bridge reaches its maximum and overflows.
Therefore, it would be desirable to provide a system and method for a broker device to push back directly to a client (i.e., when the client produces messages at a higher rate than its allowable rate, the broker device sends a negative acknowledgement to the client with a maximum allowable throughput) so that the client is able to adjust its behavior (e.g., adjusting its message throughput) such that the broker device can avoid saturation.